Shared key processing by a host to secure links

ABSTRACT

Authentication is performed on a plurality of links of a computing environment. One node requests generation of a shared key by a key server coupled to the one node. The one node obtains the shared key and an identifier of the shared key and sends the identifier from the one node to another node. A message encrypted with the shared key is sent from the one node to the other node via one link of the plurality of links. The one node receives via the one link an indication that the other node decrypted the encrypted message using the shared key obtained by the other node. The sending the encrypted message and the receiving the indication that the other node decrypted the encrypted message are repeated on one or more other links of the plurality of links using the shared key previously obtained.

BACKGROUND

One or more aspects relate, in general, to providing security withincomputing environments, and in particular, to performing authenticationfor nodes that communicate with one another via encrypted messages.

Encryption provides data security for data and/or other informationbeing transmitted between two entities, such as a source node and atarget node coupled via a plurality of endpoints or links. Tostandardize aspects of encryption, various standards are provided fordifferent types of communication protocols. For instance, the FC-SP-2and FC-LS-3 standards are provided for Fibre Channels.

The FC-SP-2 standard, as an example, used for encrypting Fibre Channellinks includes protocols for mutual authentication of two endpoints, aswell as protocols for negotiating encryption keys that are used incommunication sessions between the two endpoints. The standard providessupport for a variety of mechanisms to authenticate the involvedparties, as well as mechanisms by which key material is provided ordeveloped. The standard is defined for several authenticationinfrastructures, including secret-based, certificate-based,password-based, and pre-shared key based, as examples.

Generally, a certificate-based infrastructure is considered to provide astrong form of secure authentication, as the identity of an endpoint iscertified by a trusted Certificate Authority. The FC-SP-2 standarddefines a mechanism by which multiple certified entities can use thepublic-private key pairs that the certificate binds them to in order toauthenticate with each other. This authentication occurs directlybetween two entities through the use of the Fibre Channel Authenticationprotocol (FCAP), the design of which is based on authentication thatuses certificates and signatures as defined in, for instance, theInternet Key Exchange (IKE) protocol.

However, the exchange and validation of certificates inline is computeintensive, as well as time-consuming. The FCAP protocol is alsoperformed on every Fibre Channel link between the entities. Since it isto be done before any client traffic flows on the links that are to beintegrity and/or security protected, it can negatively impact (elongate)the link initialization times, and hence, the time it takes to bring upand begin executing client workloads. The IKE protocol also involvesfairly central processing unit intensive mathematical computations, andin an environment that includes large enterprise servers with a largenumber of Fibre Channel physical ports in a dynamic switched fabricconnected to a large number of storage controller ports, the multipliereffect of these computations and the high volume of frame exchanges tocomplete the IKE protocol can also negatively affect systeminitialization and cause constraints in heavy normal operation.

SUMMARY

Shortcomings of the prior art are overcome and additional advantages areprovided through the provision of a computer program product forfacilitating processing within a computing environment. The computerprogram product includes a computer readable storage medium readable bya processing circuit and storing instructions for performing a method.The method includes performing authentication on a plurality of links tobe used to couple one node of the computing environment and another nodeof the computing environment. The performing authentication includes,for instance, requesting by the one node generation of a shared key by akey server coupled to the one node of the computing environment. The onenode obtains the shared key and an identifier of the shared key from thekey server. The identifier of the shared key is sent from the one nodeto the other node. An encrypted message from the one node to the othernode is sent via one link of the plurality of links, the encryptedmessage encrypted with the shared key. The one node receives via the onelink an indication that the other node decrypted the encrypted messageusing the shared key obtained by the other node. The sending theencrypted message and the receiving the indication that the other nodedecrypted the encrypted message are repeated on one or more other linksof the plurality of links using the shared key previously obtained.

Authentication on a plurality of links between two nodes is performedwithout having to repeatedly obtain the shared key (e.g., wrapping key).This provides trust between the nodes and facilitates authentication ofthe links coupling the nodes. Messages communicated on the links may usethe shared key for authentication without having to repeatedly obtainthe shared key from a key server or directly between the nodes. Thisreduces processing time, and increases system performance. Linkinitialization times are also decreased, increasing efficiency incommencing client workloads and increasing system performance.

In one embodiment, the performing authentication further includesreceiving by the one node via the one link an indication that the othernode obtained the shared key from the key server.

As one example, the sending the identifier and the sending the encryptedmessage are sent as one authentication message, the one authenticationmessage including the encrypted message and the identifier that is inthe clear.

Further, in one embodiment, the indication includes a response encryptedwith the shared key. Based on receiving the response, in one example, achain of trust is extended to the one or more other links of theplurality of links to facilitate authentication of the one or more otherlinks. Based on the chain of trust, the key server is not furtheraccessed in the authenticating of the one or more other links of theplurality of links, the authenticating the one or more other linksincluding the repeating the sending the encrypted message and thereceiving the indication on the one or more other links. This reduceslink initialization time, increasing productivity and systemperformance.

In one embodiment, a secure connection is established by the one nodewith the key server, in which the establishing uses one or morecertificates installed on the one node and the key server. Theestablishing is performed, for instance, a single time for the one node,in which the performing the authentication for the plurality of linksuses the shared key obtained a single time from the key server by theone node. By establishing the secure connection with the key server onetime on the one node, system performance is improved by reducing thetime it takes to exchange and validate the certificates.

Further, in one example, the requesting generation of the shared key isbased on establishing the secure connection with the key server.Moreover, in one example, and the requesting generation of the sharedkey from the key server includes sending a create request to the keyserver requesting the shared key. Yet further, in one embodiment, theobtaining the shared key and the identifier from the key server includesobtaining from the key server, based on the requesting, an identifier ofthe shared key, sending a get request to the key server to obtain theshared key, the get request including the identifier of the shared key,and obtaining from the key server the shared key.

As an example, the encrypted message includes a set of keys to be usedto send or receive further encrypted messages.

Computer-implemented methods and computer systems relating to one ormore aspects are also described and claimed herein. Further, servicesrelating to one or more aspects are also described and may be claimedherein.

Additional features and advantages are realized through the techniquesdescribed herein. Other embodiments and aspects are described in detailherein and are considered a part of the claimed aspects.

BRIEF DESCRIPTION OF THE DRAWINGS

One or more aspects are particularly pointed out and distinctly claimedas examples in the claims at the conclusion of the specification. Theforegoing and objects, features, and advantages of one or more aspectsare apparent from the following detailed description taken inconjunction with the accompanying drawings in which:

FIG. 1 depicts one example of a computing environment to incorporate anduse one or more aspects of the present invention;

FIG. 2A depicts one example of a host of the computing environment ofFIG. 1 to incorporate and/or use one or more aspects of the presentinvention;

FIG. 2B depicts another example of a host of the computing environmentof FIG. 1 to incorporate and/or use one or more aspects of the presentinvention;

FIG. 3A depicts one example of securing a network using key serverauthentication, in accordance with one or more aspects of the presentinvention;

FIG. 3B depicts details of one embodiment of an initial authentication,in accordance with one or more aspects of the present invention;

FIG. 4 depicts one example of automating shared secret generation tosecure links on a host and/or a storage device, in accordance with oneor more aspects of the present invention;

FIG. 5A depicts one example of providing access control for connectivityrelationships using a key server, in accordance with an aspect of thepresent invention;

FIG. 5B depicts details of another embodiment of an initialauthentication, in accordance with one or more aspects of the presentinvention;

FIGS. 6A-6B depict one example of securing a path at a host using securekey exchange, in accordance with one or more aspects of the presentinvention;

FIGS. 6C-6D depict one example of securing a path at a storage deviceusing secure key exchange, in accordance with one or more aspects of thepresent invention;

FIGS. 7A-7B depict further details of one embodiment of facilitatingprocessing within a computing environment, in accordance with an aspectof the present invention;

FIG. 8A depicts another example of a computing environment toincorporate and use one or more aspects of the present invention;

FIG. 8B depicts further details of the memory of FIG. 8A;

FIG. 9 depicts one embodiment of a cloud computing environment; and

FIG. 10 depicts one example of abstraction model layers.

DETAILED DESCRIPTION

In one or more aspects, authentication is performed using certificatesout-of-band using an external key manager in order to not impact linkinitialization times. As part of authentication, the external keymanager provides for distribution of a shared key, referred to herein asa wrapping key, to each node (e.g., host, storage device) for use incommunication with one another. The wrapping key is used to transmitadditional information, such as key information, between the trustedendpoints of the nodes. This additional key information includes, forinstance, transmit (a.k.a., send) and receive keys used in theencryption/decryption of data.

Authentication, via the external key manager, between the trusted nodesthat share multiple links is performed once, instead of on a link bylink basis. The ability of both entities to receive a wrapping key(e.g., a symmetric key) as trusted entities of the external key managerand to use it to encrypt/decrypt messages between them proves mutualauthentication. Further, secure communication across all links (orselected links) connecting them is provided without additional accessesto the external key manager. Instead, the previously obtained wrappingkey is used in communications between the trusted nodes on other linkscoupling the nodes providing authentication of the links, without havingto re-authenticate the trusted nodes via the external key manager.

One example of a computing environment to include one or more aspects ofthe present invention is described with reference to FIG. 1. In oneexample, a computing environment 100 includes at least one node (e.g.,host 102) and at least one other node (e.g., storage device (SD) 104)coupled to an external key manager server 106 (also referred to hereinas external key server, key server, external key manager (EKM), asexamples) via one or more connections 108. As an example, one or moreconnections 108 are Ethernet connections protected with a TransportLayer Security (TLS) secure communication. Further, in one example, host102, storage device 104 and external key manager server 106 are coupledto a Certificate Authority (CA) 110, which is used to sign certificatesinstalled on the host, the storage device and the external key managerserver and to establish trust between them.

Host 102 includes, for instance, an external key manager (EKM) client120 coupled to an internal key store 122 for storing keys. Client 120includes the protocol used, in one example, to communicate with keyserver 106. Internal key store 122 is further coupled to Fibre Channel(FC) ports (e.g., FICON channels) 128 used to communicate with storagedevice 104, and to Ethernet ports 124, at least one of which is coupledto a port 126 of external key manager server 106 via a connection 108.(FICON is a known communication path for data between the host and thestorage device utilizing Fibre Channel technology, and Ethernet is aknown local area network.)

Similarly, in one example, storage device 104 includes an external keymanager client 130, which is used to communicate with key server 106 andis coupled to an internal key store 132 for storing keys. Internal keystore 132 is further coupled to Fibre Channel ports 136 used tocommunicate with host 102, and to Ethernet ports 134, at least one ofwhich is coupled to port 126 of external key manager server 106 via aconnection 108. Example storage devices include control units (CU),storage controllers, etc.

External key manager server 106 is used, as described below, to provideshared keys, also referred to as wrapping keys, to the host and storagedevice. It is trusted by the host and the storage device via, forinstance, certificates installed on the host, storage device and keymanager server at set-up, and signed by Certificate Authority 110.

Although examples of protocols, communication paths and technologies areprovided herein, one or more aspects are applicable to other types ofprotocols, communication paths and/or technologies. Further, other typesof nodes may employ one or more aspects of the present invention.Additionally, a node may include fewer, more, and/or differentcomponents. As an example, it may not include the internal key store.Moreover, two nodes coupled to one another may be both the same type ofnode or different types of nodes. As examples, both nodes are hosts,both nodes are storage devices, or one node is a host and another nodeis a storage device, as described in the examples herein. Manyvariations are possible.

As an example, a host may be a computing device, such as a processor, acomputer system, a central electronics complex (CEC), etc. One exampleof a computer system that may include and/or use one or more aspects ofthe present invention is depicted in FIG. 2A.

Referring to FIG. 2A, in one example, a computer system 200 is shown inthe form of a general-purpose computing device. Computer system 200includes and/or is coupled to a plurality of components, which are inaddition to and/or include the components shown in FIG. 1 including, butnot limited to, EKM client 120, internal key store 122, Ethernet ports124 and Fibre Channel ports 128, which are part of and/or coupled to thecomputer system, but not explicitly indicated in FIG. 2A. In oneexample, computer system 200 includes, but is not limited to, one ormore processors or processing units 202 (e.g., central processing units(CPUs)), a memory 204 (a.k.a., system memory, main memory, main storage,central storage or storage, as examples), and one or more input/output(I/O) interfaces 206, coupled to one another via one or more busesand/or other connections 208.

Continuing with FIG. 2A, bus 208 represents one or more of any ofseveral types of bus structures, including a memory bus or memorycontroller, a peripheral bus, an accelerated graphics port, and aprocessor or local bus using any of a variety of bus architectures. Byway of example, and not limitation, such architectures include theIndustry Standard Architecture (ISA), the Micro Channel Architecture(MCA), the Enhanced ISA (EISA), the Video Electronics StandardsAssociation (VESA) local bus, and the Peripheral Component Interconnect(PCI).

Memory 204 may include, for instance, a cache, such as a shared cache210, which may be coupled to local caches 212 of processors 202.Further, memory 204 may include one or more programs or applications214, an operating system 216, and one or more computer readable programinstructions 218. Computer readable program instructions 218 may beconfigured to carry out functions of embodiments of aspects of theinvention.

Computer system 200 may also communicate via, e.g., I/O interfaces 206with one or more external devices 220, one or more network interfaces222, and/or one or more data storage devices 224. Example externaldevices include a user terminal, a tape drive, a pointing device, adisplay, etc. Network interface 222 enables computer system 200 tocommunicate with one or more networks, such as a local area network(LAN), a general wide area network (WAN), and/or a public network (e.g.,the Internet), providing communication with other computing devices orsystems.

Data storage device 224 may store one or more programs 226, one or morecomputer readable program instructions 228, and/or data, etc. Thecomputer readable program instructions may be configured to carry outfunctions of embodiments of aspects of the invention.

Computer system 200 may include and/or be coupled toremovable/non-removable, volatile/non-volatile computer system storagemedia. For example, it may include and/or be coupled to a non-removable,non-volatile magnetic media (typically called a “hard drive”), amagnetic disk drive for reading from and writing to a removable,non-volatile magnetic disk (e.g., a “floppy disk”), and/or an opticaldisk drive for reading from or writing to a removable, non-volatileoptical disk, such as a CD-ROM, DVD-ROM or other optical media. Itshould be understood that other hardware and/or software componentscould be used in conjunction with computer system 200. Examples,include, but are not limited to: microcode, device drivers, redundantprocessing units, external disk drive arrays, RAID systems, tape drives,and data archival storage systems, etc.

Computer system 200 may be operational with numerous other generalpurpose or special purpose computing system environments orconfigurations. Examples of well-known computing systems, environments,and/or configurations that may be suitable for use with computer system200 include, but are not limited to, personal computer (PC) systems,server computer systems, thin clients, thick clients, handheld or laptopdevices, multiprocessor systems, microprocessor-based systems, set topboxes, programmable consumer electronics, network PCs, minicomputersystems, mainframe computer systems, and distributed cloud computingenvironments that include any of the above systems or devices, and thelike.

As indicated above, a computer system is one example of a host that mayincorporate and/or use one or more aspects of the present invention.Another example of a host to incorporate and/or employ one or moreaspects of the present invention is a central electronics complex, anexample of which is depicted in FIG. 2B.

Referring to FIG. 2B, in one example, a central electronics complex(CEC) 250 includes and/or is coupled to a plurality of components, whichare in addition to and/or include the components shown in FIG. 1including, but not limited to, EKM client 120, internal key store 122,Ethernet ports 124 and Fibre Channel ports 128, which are part of and/orcoupled to the central electronics complex, but not explicitly indicatedin FIG. 2B. In one example, CEC 250 includes, but is not limited to, amemory 254 (a.k.a., system memory, main memory, main storage, centralstorage, storage) coupled to one or more processors (a.k.a., centralprocessing units (CPUs)) 260, and to an input/output subsystem 262.

In one example, memory 254 of central electronics complex 250 includes,for example, one or more logical partitions 264, a hypervisor 266 thatmanages the logical partitions, and processor firmware 268. One exampleof hypervisor 266 is the Processor Resource/System Manager (PRISM),offered by International Business Machines Corporation, Armonk, N.Y. Asused herein, firmware includes, e.g., the microcode of the processor. Itincludes, for instance, the hardware-level instructions and/or datastructures used in implementation of higher level machine code. In oneembodiment, it includes, for instance, proprietary code that istypically delivered as microcode that includes trusted software ormicrocode specific to the underlying hardware and controls operatingsystem access to the system hardware.

Each logical partition 264 is capable of functioning as a separatesystem. That is, each logical partition can be independently reset, runa guest operating system 270 such as z/OS, offered by InternationalBusiness Machines Corporation, or another operating system, and operatewith different programs 282. An operating system or application programrunning in a logical partition appears to have access to a full andcomplete system, but in reality, only a portion of it is available.

Memory 254 is coupled to processors (e.g., CPUs) 260, which are physicalprocessor resources that may be allocated to the logical partitions. Forinstance, a logical partition 264 includes one or more logicalprocessors, each of which represents all or a share of a physicalprocessor resource 260 that may be dynamically allocated to the logicalpartition.

Further, memory 254 is coupled to I/O subsystem 262. I/O subsystem 262may be a part of the central electronics complex or separate therefrom.It directs the flow of information between main storage 254 andinput/output control units 256 and input/output (I/O) devices 258coupled to the central electronics complex.

While various examples of hosts are described herein, other examples arealso possible. Further, a host may also be referred to herein as asource, a server, a node, or an endpoint node, as examples.Additionally, a storage device may be referred to herein as a target, anode, or an endpoint node, as examples. Example storage devices includestorage controllers or control units. Other examples are also possible.

In one example, two nodes, such as a host (e.g., host 102) and a storagedevice (e.g., storage device 104), participate in an authenticationprotocol to provide a trust with one another. These nodes are referredto herein as peer nodes. The nodes communicate with one another via aplurality of links, and this trust extends to the links between thenodes facilitating authentication of the links, as described below. Oneexample of this protocol is described with reference to FIGS. 3A-3B.

In accordance with an aspect of the present invention, theauthentication protocol includes the use of certificates, as well as ashared key (e.g., a wrapping key), as described herein. Initially,signed certificates, signed by a Certificate Authority (e.g.,Certificate Authority 110), are installed in each host and storagedevice (e.g., each endpoint node), as well as in external key managerserver 106, STEP 300. Each node uses the certificate in an initialauthentication to authenticate itself with the external key managerserver. One embodiment of this initial authentication is furtherdescribed with reference to FIG. 3B.

Referring to FIG. 3B, signed certificates, signed by a CertificateAuthority, are installed in each of the endpoint nodes (e.g., host 102and storage device 104) and the key server (e.g., EKM 106), along with acertificate of the Certificate Authority, STEP 330. Each node uses thecertificate signed by the Certificate Authority to authenticate itselfwith the external key manager, which also includes the certificates. Theexternal key manager starts and listens on a well-known port (e.g., port126), STEP 332. The security functionality in the endpoint nodes has theInternet Protocol (IP) address of the EKM along with its pre-installedcertificate, STEP 334. The endpoint node establishes a secure session(e.g., a TLS session) with the EKM using both client and serverauthentication protocols, STEP 336. Further, the EKM obtains theidentity of the endpoint nodes, STEP 338. For instance, a descriptiveand recognizable name of the endpoint node is included in thecertificate as the identity of the endpoint node. The identifier couldhave been pre-registered into the databases of the EKM, or it can bedynamically registered and authorized through successful establishmentof the TLS session along with additional optional white-list securityadministrator action (e.g., explicit action by a user). The protocolused to exchange commands and data with the EKM is, for instance, KMIP(Key Management Interoperability Protocol) or any other proprietaryinterface protocol packaged for use within the secure TLS session. TLSand KMIP are just examples. Other protocols and secure communicationsmay be used.

Based on a node establishing a secure connection to the EKM, links tothe peer nodes can be initialized, STEP 340. As part of linkinitialization, via, for instance, a Fibre Channel Port Login (PLOGI)command, both endpoints indicate their ability to participate in asecure connection (e.g., Secure Fibre Channel Connection), in oneexample, STEP 342.

Returning to FIG. 3A, subsequent to the initial authentication with thekey server using certificates, further authentication is performed usinga shared key (e.g., a wrapping key). A wrapping key is, for instance, anAES 256 algorithm key generated by, for instance, the key server. (Inother embodiments, it is generated by another entity and stored at thekey server or in storage accessible to the key server. Otherpossibilities also exist.) It is used in the encryption/decryption ofmessages transmitted between the nodes. In one example, there is asingle wrapping key per node pair (e.g., per physical host/storagedevice pair), regardless of the logical pairings or paths between them.

In accordance with an aspect of the present invention, a wrapping key iscreated in the EKM and assigned a universal unique identifier (UUID),STEP 301. The UUID is, for instance, a KMIP (or other protocol)attribute assigned to an encryption key (e.g., the wrapping key) duringcreation. The key is created for use by the node pair by any selectedtechnique, which may be programmatic or administrative. In the examplesdescribed below, the node pair includes a host, which may be referred toas a server, and a storage device, such as a control unit. However, asindicated, this is only one example, and many variations exist.

The key UUID is made known to both the host and the storage device, STEP302. In one example, it is obtained without direct communication betweenthe node pair; however, in another example, there is communicationbetween the node pair in which the UUID is communicated from, e.g., thehost to the storage device. As specific examples, the UUID is requestedby the host and the storage device from the key server; it is programmedat the host and the storage device; it is obtained by the host andstorage device from a component other than the key server; it isrequested by one node, such as the host, from the key server, and sentfrom the one node to the other node, such as the storage device, asdescribed further below; etc. In this embodiment, the UUID may beobtained in any manner. Based on obtaining the UUID, the host and thestorage device request the wrapping key having that UUID from theexternal key manager (e.g., via the secure connection), STEP 304. Theexternal key manager provides the wrapping key directly to each node,based on the request and the UUID.

In one embodiment, the UUID and the wrapping key are obtained by thehost and the storage device absent communication with one another.Instead, both the UUID and the wrapping key associated with the UUID areindependently obtained by each node (e.g., the host and storage device).For instance, they may be obtained directly from the EKM or anotherentity. As another example, the UUID is known to both nodes, and thewrapping key is obtained directly from the EKM. Other examples are alsopossible.

In other embodiments, the wrapping key is obtained by the host andstorage device directly from the EKM without communication with oneanother, but the obtaining of the UUID by at least one of the nodesemploys communication between the nodes. Many variations are possible.

The obtaining of the wrapping key by both the peer nodes authenticatesthe peer nodes with the key server. However, in one embodiment, furtherauthentication is performed to authenticate the links coupling the peernodes. While this further authentication is performed on each desiredlink, no further authentication is performed with the key server. Asingle authentication with the key server applies to all (or selected)links coupling the peer nodes.

In one embodiment, link authentication includes the host generating amessage, encrypting that message using at least the wrapping key, andsending the encrypted message to the storage device on one of the linkscoupling the host and the storage device, STEP 306. For instance, themessage is encrypted by the host using an agreed upon encryptiontechnique, such as AES_KEYWRAP, and sent to the peer endpoint as thepayload of a new message code of the Fibre Channel Extended LinkService, known in the FC-LS-3 standard as AUTH_ELS. The storage devicereceives the AUTH_ELS and decrypts the payload utilizing the obtainedwrapping key and the deployed AES_KEYWRAP technique, STEP 308. In oneembodiment, the storage device may also respond to the message. In oneexample, the sending of the encrypted message using the wrapping key andthe successful decryption of that message using the wrapping keyauthenticates the link on which the message is sent/received. In afurther example, it is the sending of the message, encrypted using theshared key, from the host to the storage device; successful decryptionof that message using the shared key by the storage device; encryptionof a response using the shared key; sending of the encrypted response bythe storage device to the host; and successful decryption of theencrypted response by the host that completes authentication of twolinks between the trusted nodes.

In one example, the link authentication is repeated on all (or selected)links (e.g., Fibre Channel links) between the same host and storagedevice utilizing the same unique shared key defined for this pairing,STEP 310. This authenticates each link between the peer nodes withoutre-obtaining the wrapping key from the key server. The wrapping key isobtained over, e.g., the TLS connection only once per peer node, butused multiple times to authenticate each desired link between the peernodes. Therefore, the chain of trust between the nodes is extended tofacilitate authentication between all (or a selected subset of)subsequent link connections made between the host and the storage deviceendpoints.

In one particular example, the encrypted message sent on a link containsthe name identifier of the originator, and successful decryption of themessage along with validation that the included name identifier matchesthat of the originator at login completes the authentication at thestorage device. This authentication authenticates the peer nodes and thelink on which the message is sent/received.

Further, in one particular example in which the host supplies the UUIDto the storage device, the host generated message may be, for instance,the message that provides the UUID of the wrapping key to the storagedevice. The storage device then uses the UUID to obtain the wrapping keydirectly from the key server, and uses the wrapping key to decrypt thepayload. The payload may include various information, including, but notlimited to, send and receive keys to be used in other communicationsbetween the nodes.

Described in detail herein is one example of providing authentication ofa plurality of N_Ports or links in a communication fabric (e.g., FibreChannel fabric) through mutual authentication of two nodes (e.g., FibreChannel nodes) common to a key manager. In one example, the peer nodes(e.g., the host and the storage device) each authenticate to an externalkey manager, which includes configuring the IP address of the EKM in thenodes. A shared wrapping key is created by the EKM (or otherwiseobtained by the EKM) and the identifier of that key is obtained by thehost and the storage device. Further, the host and the storage deviceobtain the wrapping key directly from the EKM as trusted entities of theEKM. The host uses the key to encrypt messages sent to the storagedevice using an encryption technique (e.g., AES_KEYWRAP), and thestorage device successfully decrypts the messages to authenticate thestorage device (e.g., Fibre Channel node) as a trusted entity using thesame encryption technique. The authentication (chain of trust) isextended to all (or a selected subset) of secured logins (N_Port toN_Port links) between the host and the storage device to facilitateauthentication of all (or selected) links between the trusted nodes.

In one embodiment, the shared wrapping key is generated by the EKM uponrequest by the requesting node regardless of whether the target nodeexists. There is no need for advance association or large look-up tablesfor matching up the nodes that can communicate with one another. The keyserver generates the shared keys, in one embodiment, without knowledgeof characteristic information of the nodes; it does not even need toknow whether the target node exists. Authentication of the host and thestorage device to the EKM, rather than to each other, is enough for theEKM to share the shared key with the host and the storage device.

In one aspect, generating and obtaining of the wrapping keys isautomated, such that administrative management of the keys is notneeded. In this embodiment, a master-slave relationship is establishedbetween the nodes, in which, in one example, the host takes on the roleof the master and the storage device takes on the role of the slave.Other variations are possible.

In one aspect of automating the generating/obtaining of the wrappingkey, the master node (e.g., host 102) requests creation of the wrappingkey by the key server, obtains the UUID and the wrapping key, and passesthe UUID to the slave node (e.g., storage device 104). In a furtheraspect of the automating the obtaining, the slave node obtains the UUIDfrom the master node and using the UUID, requests the wrapping keydirectly from the key server. The same wrapping key is used toencrypt/decrypt communications on the links between the master node andthe slave node. These communications may be used to exchange further keyinformation (e.g., send/receive keys) used to protect I/O operationdata. Further details regarding these aspects of generating/obtainingthe wrapping key are described with reference to FIG. 4.

Referring to FIG. 4, in one example, initial authentication takes place,in which the master node (e.g., host 102) and the slave node (e.g.,storage device 104) authenticate themselves using, e.g., certificateswith the key manager server (e.g., key server 106), STEP 400. Oneexample of this initial authentication is described with reference toFIG. 3B. Further, in one embodiment, prior to authentication of a firstsecurity capable link between the host and the storage device, the hostinitiates the creation of a unique shared key (e.g., wrapping key) to beused by the host/storage device pair. For instance, the host sends aCreate Key Request to the external key manager server using, e.g.,secure connection 108, STEP 401. Based on the create request, externalkey manager server 106 creates a wrapping key (wk) and responds with auniversally unique identifier (UUID) for the wrapping key, STEP 402.Based on receiving the UUID, the host follows-up with a request for thewrapping key by sending, for instance, a Get Key request using the UUIDobtained from external key manager server 106, STEP 404. The externalkey manager server responds with a wrapping key, STEP 406.

In one example, based on receiving the wrapping key, the host generatesa message, encrypts the message using the wrapping key, and appends theUUID in the clear, STEP 410. In one example, the message includes otherkey information, such as send/receive keys to be used inencryption/decryption of messages transmitted between the host and theparticular storage device. For instance, a host reads from and writesdata to a storage device through a communication channel, such as aFibre Channel, Infiniband, or a TCP/IP network. The data communicatedbetween the host and the storage device is encrypted using a set ofencryption keys, called send and receive keys. A send or transmit keyis, for instance, an AES (Advanced Encryption Standard) 256 algorithmkey stored, e.g., in a register of communication adapters between a hostand a storage device, and used to encrypt and decrypt customer dataflowing between the storage device and the host. A receive key is, forinstance, an AES 256 algorithm key stored in, e.g., a register ofcommunication adapters between a host and a storage device, and used toencrypt and decrypt data flowing between the storage device and thehost. However, other examples are possible, in which the messageincludes other data or information.

The host sends to the storage device over a link (e.g., a Fibre Channellink) an authorization message (e.g., an Auth_ELS FC command) thatincludes, for instance, the UUID of the wrapping key in the clear, anagreed upon encryption technique (e.g., AES Keywrap) and the encryptedmessage, STEP 412. The host receives over the link an acknowledgement tothe authorization message (e.g., a LS_ACC ELS response) from the storagedevice, STEP 414. Further, in one embodiment, the host receives aresponse message from the storage device, which includes contentencrypted with the wrapping key, STEP 416. The host decrypts the contentusing the same wrapping key to complete the authentication processthrough validation of the received message, STEP 418. Further, in oneembodiment, the host acknowledges receipt of the response, STEP 422.

In one embodiment, the host sends an authorization message thatincludes, for instance, the UUID of the wrapping key generated for thishost-storage device pair in the clear, an agreed upon encryptiontechnique (e.g., AES Keywrap), and an encrypted message to each securelink to be established between the host-storage device pair. Thisfacilitates authentication on each selected link without requiringadditional requests of the wrapping key from the key server, and withoutfurther authentication of the host and storage device with the keyserver (e.g., only one authentication per node with the key server isperformed).

Thus, in accordance with one or more aspects of the present invention,the master node (e.g., host 102) initiates creation of the wrapping keyat the key server, obtains the wrapping key from the key server, andpasses an UUID of the wrapping key to the slave node (e.g., storagedevice 104) to enable the slave node to retrieve the same wrapping keyfrom the key server.

Processing associated with the role of the slave node (e.g., storagedevice 104) in the wrapping key generation, distribution and processingis now described with reference to FIG. 4. Based on the storage devicereceiving the authentication message, which includes the UUID, theagreed upon encryption technique, and the encrypted message, over a linkcoupling the storage device and the host, in one embodiment, the storagedevice acknowledges to the host successful receipt of the authenticationmessage, STEP 414. This acknowledgement is performed, in one embodiment,for each authentication message received over each link that is to beauthenticated.

Further, in one embodiment, based on the storage device receiving afirst authentication message from the host on a link coupling the hostand the storage device, the storage device parses the message to obtainthe UUID, and then obtains the wrapping key associated with the UUID,STEP 420. In one embodiment, the storage device attempts to retrieve thewrapping key from its local key store (e.g., internal key store 132),STEP 420, but if the wrapping key is, e.g., a new key, and therefore,not in the internal store yet, the storage device requests the wrappingkey from the external key manager server 106, STEP 422. External keyserver 106 responds with the wrapping key, STEP 424, and the storagedevice decrypts the encrypted message using the wrapping key and theagreed upon encryption technique to complete, in one embodiment, theauthentication process. In a further embodiment, the storage devicesends an encrypted response to the host indicating successful decryptionof the message, STEP 416, which the host decrypts to completeauthorization, STEP 418.

The obtaining of the wrapping key by the storage device is performed, inone example, on the first receipt of the encrypted message with theUUID. It is not performed for authentication of the other links couplingthe host and the storage device. Instead, for the other links, the samewrapping key, previously obtained by the storage device from the keyserver (or otherwise), is used to decrypt the message and send anencrypted response to the host. The wrapping key obtained from the hostand the storage device may be used to encrypt/decrypt communications onall (or a selected subset) of the links between the host and the storagedevice.

As described above, in one embodiment, the master (e.g., host 102)obtains the wrapping key and passes the UUID of the wrapping key to thestorage device (e.g., storage device 104) via a link established betweenthe host and the storage device. The storage device uses the UUID passedto it in a message over the link (e.g., the first link to receive themessage) to obtain the wrapping key from, for instance, the external keymanager. The wrapping key is then used to encrypt/decrypt communicationson all (or selected) links between the host and the storage device.

In one aspect, the external key server dynamically generates the secretshared wrapping key upon request of the master node, and shares thatwrapping key, e.g., only with the properly designated communicationpartner. The created wrapping key is specifically for the master/slavenode pair, such that only the authorized pair of nodes has access to thewrapping key (besides the external key manager). The target node usesthe wrapping key to unwrap (i.e., decrypt) other information, such assend/receive keys. Thus, the send/receive keys are not known to theexternal key manager, which enhances security of the send/receive keysand the system.

In a further aspect, authentication includes the use of an alternatename for one or more of the nodes. This alternate name is, for instance,a World-Wide Node Name (WWNN) associated with an endpoint node. In oneembodiment, certificates provide multiple fields that can be set at thediscretion of the certificate creator, including an alternate namefield. The Fibre Channel FC-FS-4 standard, as an example, provides amechanism by which each Fibre Channel node is assigned a World-Wide NodeName, which is designed to be unique within a Fibre Channel name space.The WWNN associated with an endpoint node can also be obtained by anentity connected to the endpoint node through utilizing Extended LinkService commands provided by the FC-LS-3 standard. One embodimentdescribed below employs the WWNN of the host or the storage devicespecified in the alternate name field of the signed certificate. Thisenables finer granularity of access control, since the nodes permittedto communicate with one another may be controlled using the alternatenames. For instance, an indication is maintained of which storagecontrollers the host may communicate with, etc. Further, in accordancewith an aspect of the present invention, access of the shared key isfurther controlled by the master node indicating which slave node is toshare the wrapping key with the master node.

As an example, when the host connects to a storage device, it queriesthe WWNN of the attached storage device. When it makes a request to theexternal key manager to create a shared key (e.g., a symmetric wrappingkey), it includes the WWNN of the storage device peer to which it wantsthe shared key to be accessible (in addition to itself as creator).Thus, in this embodiment, the external key manager only serves theshared key to the creator and to the entity whose certificate containedthe WWNN in the alternate name field. One example of this embodiment isfurther described below with reference to FIG. 5A.

Referring to FIG. 5A, in one example, one node (e.g., host 102) andanother node (e.g., storage device 104) participate in an authenticationprotocol to provide trust with one another. Initially, signedcertificates, signed by a Certificate Authority (e.g., CertificateAuthority 110), are installed in each endpoint node (e.g., host andstorage device), as well as in in the external key manager server, STEP500. Each node uses the certificate to authenticate itself with theexternal key manager server. One embodiment of this initialauthentication is further described with reference to FIG. 5B.

Referring to FIG. 5B, signed certificates, signed by a CertificateAuthority, are installed in each of the endpoint nodes (e.g., host andstorage device) and the key server, along with a certificate of theCertificate Authority, STEP 530. Each node uses the certificate toauthenticate itself with the external key manager, which also includesthe certificates. The external key manager starts and listens on awell-known port (e.g., port 126), STEP 532. The security functionalityin the endpoint nodes has the Internet Protocol (IP) address of the EKMalong with its pre-installed certificate, STEP 534. A descriptive andrecognizable name of the endpoint node (e.g., the Fibre ChannelWorld-Wide Node Name) is included in the ‘Subject Alternative Name’field of the certificate as the identity of the endpoint node, STEP 535.The endpoint node establishes a secure session (e.g., a TLS session)with the EKM using both client and server authentication protocols, STEP536. The EKM associates the WWNN with the IP address and otherinformation by which the authenticated entity is known to it, STEP 538.

Further, in one embodiment, the Security Administrator (or other entity)for the computing environment may classify the full set of authorizedendpoint nodes into groups, limiting access between sets of endpoints inthe larger pool of authorized entities, STEP 540. For instance, it isthe responsibility of the Security Administrator to install certificateswith appropriate roots of trust on nodes. A group of available andallowed peers may be set by the Security Administrator through thecombination of which nodes valid certificates are installed, along withthe establishment of some form of group definition at the key server.The key server may require or allow, in one embodiment, the SecurityAdministrator to additionally explicitly permit or authorize an endpointnode into the pool or a specific grouping after it has successfullycompleted the TLS authentication process, STEP 542. The protocol used toexchange subsequent commands and data with the EKM can be KMIP or anyother proprietary interface protocol packaged for use within the secureTLS session. In other embodiments, other protocols and/or securecommunications may be used.

Based on a node establishing a secure connection to the EKM, links tothe peer nodes can be initialized, STEP 544. The list of authorizedconnections may be provided by an authorized system I/O administratorthrough a configuration file. In IBM Z, this configuration file is knownas an I/O configuration Data Set (IOCDS), but could also be specifiedvia other means such as through a graphical user interface (GUI) on theEKM or at one or more endpoint nodes, as examples. Additionally (orinstead of the I/O configuration file), a SAN (Storage Area Network)administrator establishes fabric zoning policies limiting access ofendpoints to each other through the fabric, and those policies are inputto the SAN for enforcement. Many possibilities exist.

As part of link initialization, via, for instance, a Fibre Channel PortLogin (PLOGI) command, both endpoints indicate their ability toparticipate in a secure connection (e.g., Fibre Channel connection), inone example, STEP 546. Further, in one embodiment, as part of or priorto link initialization, by a pre-established convention or set of rules,one endpoint node assumes the role of a master in a master/slaverelationship for the connection. If both endpoints have indicated anability to establish a secure link, on a select (e.g., first)communication between the two nodes, the master endpoint node (e.g., thehost) requests that a shared secret (e.g., wrapping key) be created foruse in further communication with the peer endpoint node (e.g., storagedevice), as described herein. The peer is identified using the samedescriptive, recognizable and unique name (WWNN) that was contained inthe peer certificate utilized during the TLS session establishment. TheEKM enforces that this key can be retrieved, e.g., only by the endpointnode that created it and the particular peer endpoint node for which itwas created. The distribution of the wrapping key can occur via a pullmode where each endpoint node requests a key based on the identifiervalue, a push model where the EKM sends the created key to the twoparties that are in the membership domain for this key, or a combinationof both in which one entity pulls the wrapping key information, and theother entity is pushed the wrapping key information. Other variationsalso exist. Further details regarding the distribution of the shared keyare described with reference to FIG. 5A.

Referring to FIG. 5A, in accordance with an aspect of the presentinvention, the master node (e.g., host 102) initiates the creation of awrapping key by an external key server (e.g., external key managerserver 106) by, for instance, sending a Create Key Request to theexternal key manager server using secure connection 108, STEP 502. Inaccordance with this aspect of the present invention, the WWNN of theslave node (e.g., the control unit (CU) WWNN) is passed to the EKM aspart of the request. Based on the create request, external key managerserver 106 creates a wrapping key (wk) and responds with a universallyunique identifier (UUID) for the wrapping key, STEP 504. Based onreceiving the UUID, the host follows-up with a request for the wrappingkey by sending, for instance, a Get Key request using the UUID obtainedfrom external key manager server 106, STEP 506. The external key managerserver responds with a wrapping key, STEP 508.

Based on receiving the wrapping key, the host generates a message, andencrypts the message using the wrapping key, STEP 510. In one example,the message includes other key information, such as send/receive keys tobe used in encryption/decryption of messages transmitted between thehost and the particular storage device. The host sends an authorizationmessage (e.g., an Auth_ELS FC command) to the storage device over a linkthat includes, for instance, the UUID of the wrapping key in the clear,an agreed upon encryption technique, and the encrypted message, STEP512. In one example, the storage device responds with an acknowledgement(e.g., a LS_ACC ELS response) to the authorization message, STEP 514.

Further, in accordance with an aspect of the present invention, based onreceiving the UUID and the encrypted message, the storage device parsesthe message to obtain the UUID, and uses the UUID to obtains thewrapping key associated with the UUID, STEP 520. In one embodiment, thestorage device attempts to retrieve the wrapping key from its local keystore (e.g., internal key store 132), STEP 520, but if the wrapping keyis not in the internal store, the storage device requests the wrappingkey from, e.g., external key manager server 106, STEP 522. In oneembodiment, external key manager server 106 determines whether thestorage device is in the same authorized pool as the host and/or whetherthe storage device was identified as the peer for this host (e.g., inthe certificate shared with the key server), STEP 526. If the key serverdetermines that the storage device is authorized to receive the sharedkey, the key server responds with the wrapping key, STEP 524. If,however, the storage device is not in the same pool or is not identifiedas the peer, it will not be successful in retrieving the key from thekey server and no further communication between the endpoint nodes willbe performed until, for instance, a relevant security policy changes.Although various security policies are described herein, others may beused without departing from a spirit of aspects of the presentinvention.

In one embodiment, assuming the storage device is successful inobtaining the shared key, to complete authentication on this link, thestorage device encrypts a response message using the shared key andsends the encrypted response message to the host, which decrypts it.Successful decryption of the response, in one embodiment, indicatessuccessful authentication.

If the storage device is successful in obtaining the wrapping key, thenthe wrapping key is used, for instance, to encrypt/decryptcommunications on all (or a selected subset) of the links between thehost and the storage device. The wrapping key is used in authenticatingother links coupling the host and the storage device without requiringthe further obtaining of the wrapping key from the key server.Authentication with the key server is performed, e.g., once, and thenthe obtained wrapping key is used in link authentication for a pluralityof links between the peer nodes.

Described above is one embodiment of a key server providing peer to peeraccess control between two nodes (e.g., Fibre Channel nodes). In oneexample, each node in, for instance, a Fibre Channel SAN identifies analternate name in a certificate used for key server authentication. Forinstance, the Fibre Channel WWNN is placed in an alternate name field ofthe certificate. A host provides the alternate name of a peer to the EKMduring a create key request. In one example, an IOCDS is used by thehost to determine peers to which secure access is allowed. The keyserver uses the alternate name to serve the key to select entities(e.g., the requestor of the key and the named peer).

The above described methodology is used to provide access control in,for instance, secure Fibre Channel relationships between two nodesconnected via links (e.g., physical connections, such as Fibre Channellinks), in which the two nodes are a host and a storage device, twohosts, or two storage devices, etc. The node that assumes the masterrole is determined, for example, through administrative configuration orvia an automated convention. Many variations are possible.

A further embodiment relating to peer nodes (e.g., a host and a storagedevice) securing a Fibre Channel path at their end using the secure keyexchange is described with reference to FIGS. 6A-6D. FIGS. 6A-6Bhighlight example tasks performed by the master node (e.g., host orserver), and FIGS. 6C-6D highlight example tasks performed by the slavenode (e.g., storage device, such as a storage controller).

Referring to FIGS. 6A-6B, as described above, initially, signedcertificates are installed in each endpoint node (e.g., each host andstorage device) and the key server, along with the certificate of theCertificate Authority, STEP 600. As described above (e.g., FIG. 3Band/or FIG. 5B), each node uses the certificate to authenticate itselfwith an external key manager server (e.g., EKM 106). The EKM starts andlistens on a well-known port. The security functionality in the endpointnodes has the IP address of the EKM along with its pre-installedcertificate. The endpoint node establishes a secure session (e.g., a TLSsession) with the EKM using both client and server authentication flows.A descriptive and recognizable name of the endpoint node is included inthe certificate as the identity of the endpoint node. This identifiercould have been pre-registered into the database of the EKM or it can bedynamically registered and authorized through successful establishmentof the TLS session along with additional optional white-list securityadministrator action upon establishment of the TLS session. The protocolused to exchange commands and data with the EKM is, for instance, KMIPor any other proprietary interface protocol packaged for use within thesecure TLS session.

In one aspect, based on a node establishing a secure connection to theEKM over one link, other links to the peer nodes can be initialized. Aspart of link initialization (e.g., processing the Fibre Channel PortLogin (PLOGI) command), both endpoints indicate, for instance, theirability to participate in a secure connection by, for instance, settinga security capable indicator (e.g., a bit). Other mechanisms are alsopossible.

Continuing with FIG. 6A, in one embodiment, a wrapping key is createdfor use by peer nodes (e.g., a host and storage device pairing) byeither a programmatic or administrative mechanism, using an external keymanager, and this shared wrapping key is assigned a UUID, STEP 601. Ifboth endpoint nodes have indicated an ability to establish a securelink, as trusted entities of the EKM, each endpoint node obtains thewrapping key. For instance, each node retrieves the wrapping key fromthe EKM, based on a first communication between the nodes. In otherembodiments, each node obtains the wrapping key in another manner, suchas from an internal key store. Other variations are also possible.

Based on obtaining the wrapping key, the wrapping key is used in furthercommunication between the peer nodes on one or more links coupling thenodes. This is described in further detail with reference to FIGS.6A-6B. In one embodiment, the host (e.g., server) assumes the role ofmaster in a master/slave relationship, STEP 610. The server generates orotherwise obtains a first set of key material, such as a firstencryption key (e.g., a send or transmit key) and one or more firstencryption parameters, such as, e.g., a salt (e.g., random data used inencryption) and a Security Parameters Index (SPI) (e.g., anidentification tag), to be used for the transmission of I/O command datafrom the master node (e.g., server) to the slave node (e.g., storagedevice) on the link (and used by the storage device on reception of I/Ocommand data from the server), STEPS 602, 612. Further, the servergenerates or otherwise obtains a second set of key material, such as asecond encryption key (e.g., a receive key) and one or more secondencryption parameters, such as a salt, to be used for the transmissionof I/O command data from the storage device to the server on the link(and used by the server on reception of this data from the storagedevice), STEPS 602, 614.

The server generates a message, encrypts the message using at least thewrapping key, and sends the encrypted message to the storage device,STEPS 603, 616. For instance, the message is encrypted by the serverusing an AES_KEYWRAP technique (or other suitable technique) and sent tothe storage device as the payload of a new Secure Key Exchange messagecode of the Fibre Channel Extended Link Service, known in the FC-LS-3standard as AUTH_ELS. The only part of the payload that is sent in theclear is, for instance, the identifier (UUID) of the wrapping key thatwas created and stored within, e.g., the EKM. The payload includes, forinstance, the first and second keys, the two salts, the SPI, and theencryption technique to be used, which are encrypted with the wrappingkey, and the UUID in the clear.

Subsequently, the server receives an acknowledgment message (e.g.,LS_ACC) from the storage controller acknowledging receipt of themessage, STEP 604. Additionally, in one embodiment, the server receivesan encrypted response message from the storage controller, which isencrypted with the wrapping key, STEP 618, 654. The server decrypts theencrypted response message using the wrapping key retrieved from the EKMand deploying the AES_KEYWRAP or other suitable technique, STEP 620. Theserver processes the decrypted message, which includes an SPI associatedwith the second encryption key and salt, STEP 622.

In one example, the server loads the send and receive keys into the hostbus adapter's (HBA's) cryptographic configuration or other suitablelocation, STEPS 606, 624. The server utilizes, in one example, the firstencryption key (e.g., send key), salt and SPI to securely transmitsubsequent command data to the storage controller, STEP 626. The serverutilizes the second encryption key (e.g., receive key), salt and SPI todecrypt subsequent command data received from the storage controllerendpoint, STEPS 608, 628. This enables secure communication between thepeer nodes, which is facilitated by the use of the wrapping key obtainedfrom the external key server.

As indicated above, the server sends an Auth_ELS with a wrapped packageto the storage device, such as a storage controller, and the storagecontroller processes the message, as described with reference to FIGS.6C-6D. In this example, the storage controller assumes the role of slavein the master/slave relationship, STEP 660. The storage controllerreceives a message containing an encrypted secure key exchange request(e.g., Auth_ELS), and unwraps the message, STEPS 650, 662. The messageincludes, for instance, the encrypted payload and the UUID of thewrapping key, in the clear. The storage controller acknowledgessuccessful receipt of the message to the originating server, STEPS 604,664. If not already in possession of the wrapping key identified in themessage payload by the UUID, the storage controller retrieves thewrapping key from, e.g., the EKM, STEP 666. The storage controllerutilizes the shared wrapping key and the agreed upon encryptiontechnique to decrypt the message payload, which includes a firstencryption key (e.g., send key), an associated salt and SPI, and asecond encryption key (e.g., receive key) and associated salt, STEP 668.The storage controller loads the send/receive keys from the decryptedmessage into, for instance, the HBA's cryptographic configuration oranother defined location, STEPS 652, 670. The storage controllergenerates a second SPI value to be associated with the second encryptionkey and salt, STEP 672. The storage controller builds a response messagethat includes the second SPI in the payload, and encrypts this messageusing the wrapping key and the designated encryption technique (e.g.,AES_KEYWRAP), STEP 674.

The storage controller sends the encrypted message to the serverendpoint node, STEPS 654, 676, and the storage controller endpoint nodewaits to receive a response acknowledging successful receipt of theencrypted message it sent, STEPS 656, 678.

The storage controller utilizes the first encryption key, salt and SPIto securely receive subsequent command data sent from the server, STEP680. Further, the storage controller utilizes the second encryption key,SALT and SPI to encrypt subsequent command data sent to the server, STEP682.

As described above, a master/slave relationship is established betweentwo nodes (e.g., a host and a storage device), with one node (e.g., thehost) assuming the role of master. The master creates or otherwiseobtains unique key material (e.g., send/receive keys), and otherassociated parameters (e.g., salts, SPI) for use on each link betweenthe nodes for both sending and receiving data in subsequent I/Ooperations between the two nodes on the link (although one parameter,e.g., an SPI, is created by the slave node (e.g., storage device) andsent to the master). The key material and parameters are exchanged inmessages protected by a shared wrapping key served previously to thepeer nodes by the external key manager. Based on the message passingbeing completed in both directions, the endpoints utilize the new keymaterial to securely transmit and receive I/O command data. In oneembodiment, the slave node receives an identifier of the shared wrappingkey that is used to decrypt a message containing send/receive keys. Ifthe slave can successfully decrypt the message, the master isauthenticated. A single message is used with less cryptographicoperations, in one embodiment.

Although various embodiments are described herein, other variations andembodiments are possible.

One or more aspects of the present invention are inextricably tied tocomputer technology and facilitate processing within a computer,improving performance thereof. In one example, performance enhancementis provided in authenticating links between nodes. These links are usedto securely transmit messages between the nodes coupled by the links.One or more aspects reduce link initialization time, increaseproductivity within the computer environment, enhance security withinthe computer environment, and/or increase system performance.

One particular example of facilitating processing within a computingenvironment, as it relates to link authentication, is described withreference to FIGS. 7A-7B. Referring to FIG. 7A, in one aspect,authentication is performed on a plurality of links to be used to coupleone node of the computing environment and another node of the computingenvironment (700). The performing authentication includes, for instance,requesting by the one node generation of a shared key by a key servercoupled to the one node of the computing environment (702). The one nodeobtains the shared key and an identifier of the shared key from the keyserver (704). The identifier of the shared key is sent from the one nodeto the other node (706). An encrypted message is sent from the one nodeto the other node via one link of the plurality of links, the encryptedmessage encrypted with the shared key (708). The one node receives viathe one link an indication that the other node decrypted the encryptedmessage using the shared key obtained by the other node (710). Thesending the encrypted message and the receiving the indication that theother node decrypted the encrypted message are repeated on one or moreother links of the plurality of links using the shared key previouslyobtained (712).

In one embodiment, the performing authentication further includesreceiving by the one node via the one link an indication that the othernode obtained the shared key from the key server (714).

As one example, the sending the identifier and the sending the encryptedmessage are sent as one authentication message, the one authenticationmessage including the encrypted message and the identifier that is inthe clear (716). Further, in one embodiment, the indication includes aresponse encrypted with the shared key (718).

In one example, referring to FIG. 7B, based on receiving the response, achain of trust is extended to the one or more other links of theplurality of links to facilitate authentication of the one or more otherlinks (720). Based on the chain of trust, the key server is not furtheraccessed in the authenticating of the one or more other links of theplurality of links, the authenticating the one or more other linksincluding the repeating the sending the encrypted message and thereceiving the indication on the one or more other links (722).

In one embodiment, a secure connection is established by the one nodewith the key server, in which the establishing uses one or morecertificates installed on the one node and the key server (724). Theestablishing is performed, for instance, a single time for the one node,in which the performing the authentication for the plurality of linksuses the shared key obtained a single time from the key server by theone node (726).

Further, as examples, the requesting generation of the shared key isbased on establishing the secure connection with the key server (728),and the requesting generation of the shared key from the key serverincludes sending a create request to the key server requesting theshared key (730). Yet further, in one embodiment, the obtaining theshared key and the identifier from the key server further includesobtaining from the key server, based on the requesting, an identifier ofthe shared key, sending a get request to the key server to obtain theshared key, the get request including the identifier of the shared key,and obtaining from the key server the shared key (732).

As an example, the encrypted message includes a set of keys to be usedto send or receive further encrypted messages (734).

Many variations are possible.

Further other types of computing environments may also incorporate anduse one or more aspects of the present invention, including, but notlimited to, emulation environments, an example of which is describedwith reference to FIG. 8A. In this example, a computing environment 35includes, for instance, a native central processing unit (CPU) 37, amemory 39, and one or more input/output devices and/or interfaces 41coupled to one another via, for example, one or more buses 43 and/orother connections. As examples, computing environment 35 may include aPowerPC processor offered by International Business MachinesCorporation, Armonk, N.Y.; and/or other machines based on architecturesoffered by International Business Machines Corporation, Intel, or othercompanies.

Native central processing unit 37 includes one or more native registers45, such as one or more general purpose registers and/or one or morespecial purpose registers used during processing within the environment.These registers include information that represents the state of theenvironment at any particular point in time.

Moreover, native central processing unit 37 executes instructions andcode that are stored in memory 39. In one particular example, thecentral processing unit executes emulator code 47 stored in memory 39.This code enables the computing environment configured in onearchitecture to emulate another architecture. For instance, emulatorcode 47 allows machines based on architectures other than thez/Architecture, such as PowerPC processors, or other servers orprocessors, to emulate the z/Architecture and to execute software andinstructions developed based on the z/Architecture.

Further details relating to emulator code 47 are described withreference to FIG. 8B. Guest instructions 49 stored in memory 39 comprisesoftware instructions (e.g., correlating to machine instructions) thatwere developed to be executed in an architecture other than that ofnative CPU 37. For example, guest instructions 49 may have been designedto execute on a z/Architecture processor, but instead, are beingemulated on native CPU 37, which may be, for example, an Intelprocessor. In one example, emulator code 47 includes an instructionfetching routine 51 to obtain one or more guest instructions 49 frommemory 39, and to optionally provide local buffering for theinstructions obtained. It also includes an instruction translationroutine 53 to determine the type of guest instruction that has beenobtained and to translate the guest instruction into one or morecorresponding native instructions 55. This translation includes, forinstance, identifying the function to be performed by the guestinstruction and choosing the native instruction(s) to perform thatfunction.

Further, emulator code 47 includes an emulation control routine 57 tocause the native instructions to be executed. Emulation control routine57 may cause native CPU 37 to execute a routine of native instructionsthat emulate one or more previously obtained guest instructions and, atthe conclusion of such execution, return control to the instructionfetch routine to emulate the obtaining of the next guest instruction ora group of guest instructions. Execution of native instructions 55 mayinclude loading data into a register from memory 39; storing data backto memory from a register; or performing some type of arithmetic orlogic operation, as determined by the translation routine.

Each routine is, for instance, implemented in software, which is storedin memory and executed by native central processing unit 37. In otherexamples, one or more of the routines or operations are implemented infirmware, hardware, software or some combination thereof. The registersof the emulated processor may be emulated using registers 45 of thenative CPU or by using locations in memory 39. In embodiments, guestinstructions 49, native instructions 55 and emulator code 37 may residein the same memory or may be disbursed among different memory devices.

One or more aspects may relate to cloud computing.

It is to be understood that although this disclosure includes a detaileddescription on cloud computing, implementation of the teachings recitedherein are not limited to a cloud computing environment. Rather,embodiments of the present invention are capable of being implemented inconjunction with any other type of computing environment now known orlater developed.

Cloud computing is a model of service delivery for enabling convenient,on-demand network access to a shared pool of configurable computingresources (e.g., networks, network bandwidth, servers, processing,memory, storage, applications, virtual machines, and services) that canbe rapidly provisioned and released with minimal management effort orinteraction with a provider of the service. This cloud model may includeat least five characteristics, at least three service models, and atleast four deployment models.

Characteristics are as follows:

On-demand self-service: a cloud consumer can unilaterally provisioncomputing capabilities, such as server time and network storage, asneeded automatically without requiring human interaction with theservice's provider.

Broad network access: capabilities are available over a network andaccessed through standard mechanisms that promote use by heterogeneousthin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

Resource pooling: the provider's computing resources are pooled to servemultiple consumers using a multi-tenant model, with different physicaland virtual resources dynamically assigned and reassigned according todemand. There is a sense of location independence in that the consumergenerally has no control or knowledge over the exact location of theprovided resources but may be able to specify location at a higher levelof abstraction (e.g., country, state, or datacenter).

Rapid elasticity: capabilities can be rapidly and elasticallyprovisioned, in some cases automatically, to quickly scale out andrapidly released to quickly scale in. To the consumer, the capabilitiesavailable for provisioning often appear to be unlimited and can bepurchased in any quantity at any time.

Measured service: cloud systems automatically control and optimizeresource use by leveraging a metering capability at some level ofabstraction appropriate to the type of service (e.g., storage,processing, bandwidth, and active user accounts). Resource usage can bemonitored, controlled, and reported, providing transparency for both theprovider and consumer of the utilized service.

Service Models are as follows:

Software as a Service (SaaS): the capability provided to the consumer isto use the provider's applications running on a cloud infrastructure.The applications are accessible from various client devices through athin client interface such as a web browser (e.g., web-based email). Theconsumer does not manage or control the underlying cloud infrastructureincluding network, servers, operating systems, storage, or evenindividual application capabilities, with the possible exception oflimited user-specific application configuration settings.

Platform as a Service (PaaS): the capability provided to the consumer isto deploy onto the cloud infrastructure consumer-created or acquiredapplications created using programming languages and tools supported bythe provider. The consumer does not manage or control the underlyingcloud infrastructure including networks, servers, operating systems, orstorage, but has control over the deployed applications and possiblyapplication hosting environment configurations.

Infrastructure as a Service (IaaS): the capability provided to theconsumer is to provision processing, storage, networks, and otherfundamental computing resources where the consumer is able to deploy andrun arbitrary software, which can include operating systems andapplications. The consumer does not manage or control the underlyingcloud infrastructure but has control over operating systems, storage,deployed applications, and possibly limited control of select networkingcomponents (e.g., host firewalls).

Deployment Models are as follows:

Private cloud: the cloud infrastructure is operated solely for anorganization. It may be managed by the organization or a third party andmay exist on-premises or off-premises.

Community cloud: the cloud infrastructure is shared by severalorganizations and supports a specific community that has shared concerns(e.g., mission, security requirements, policy, and complianceconsiderations). It may be managed by the organizations or a third partyand may exist on-premises or off-premises.

Public cloud: the cloud infrastructure is made available to the generalpublic or a large industry group and is owned by an organization sellingcloud services.

Hybrid cloud: the cloud infrastructure is a composition of two or moreclouds (private, community, or public) that remain unique entities butare bound together by standardized or proprietary technology thatenables data and application portability (e.g., cloud bursting forload-balancing between clouds).

A cloud computing environment is service oriented with a focus onstatelessness, low coupling, modularity, and semantic interoperability.At the heart of cloud computing is an infrastructure that includes anetwork of interconnected nodes.

Referring now to FIG. 9, illustrative cloud computing environment 50 isdepicted. As shown, cloud computing environment 50 includes one or morecloud computing nodes 52 with which local computing devices used bycloud consumers, such as, for example, personal digital assistant (PDA)or cellular telephone 54A, desktop computer 54B, laptop computer 54C,and/or automobile computer system 54N may communicate. Nodes 52 maycommunicate with one another. They may be grouped (not shown) physicallyor virtually, in one or more networks, such as Private, Community,Public, or Hybrid clouds as described hereinabove, or a combinationthereof. This allows cloud computing environment 50 to offerinfrastructure, platforms and/or software as services for which a cloudconsumer does not need to maintain resources on a local computingdevice. It is understood that the types of computing devices 54A-N shownin FIG. 9 are intended to be illustrative only and that computing nodes52 and cloud computing environment 50 can communicate with any type ofcomputerized device over any type of network and/or network addressableconnection (e.g., using a web browser).

Referring now to FIG. 10, a set of functional abstraction layersprovided by cloud computing environment 50 (FIG. 9) is shown. It shouldbe understood in advance that the components, layers, and functionsshown in FIG. 10 are intended to be illustrative only and embodiments ofthe invention are not limited thereto. As depicted, the following layersand corresponding functions are provided:

Hardware and software layer 60 includes hardware and softwarecomponents. Examples of hardware components include: mainframes 61; RISC(Reduced Instruction Set Computer) architecture based servers 62;servers 63; blade servers 64; storage devices 65; and networks andnetworking components 66. In some embodiments, software componentsinclude network application server software 67 and database software 68.

Virtualization layer 70 provides an abstraction layer from which thefollowing examples of virtual entities may be provided: virtual servers71; virtual storage 72; virtual networks 73, including virtual privatenetworks; virtual applications and operating systems 74; and virtualclients 75.

In one example, management layer 80 may provide the functions describedbelow. Resource provisioning 81 provides dynamic procurement ofcomputing resources and other resources that are utilized to performtasks within the cloud computing environment. Metering and Pricing 82provide cost tracking as resources are utilized within the cloudcomputing environment, and billing or invoicing for consumption of theseresources. In one example, these resources may include applicationsoftware licenses. Security provides identity verification for cloudconsumers and tasks, as well as protection for data and other resources.User portal 83 provides access to the cloud computing environment forconsumers and system administrators. Service level management 84provides cloud computing resource allocation and management such thatrequired service levels are met. Service Level Agreement (SLA) planningand fulfillment 85 provide pre-arrangement for, and procurement of,cloud computing resources for which a future requirement is anticipatedin accordance with an SLA.

Workloads layer 90 provides examples of functionality for which thecloud computing environment may be utilized. Examples of workloads andfunctions which may be provided from this layer include: mapping andnavigation 91; software development and lifecycle management 92; virtualclassroom education delivery 93; data analytics processing 94;transaction processing 95; and authentication processing 96.

Aspects of the present invention may be a system, a method, and/or acomputer program product at any possible technical detail level ofintegration. The computer program product may include a computerreadable storage medium (or media) having computer readable programinstructions thereon for causing a processor to carry out aspects of thepresent invention.

The computer readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, configuration data for integrated circuitry, oreither source code or object code written in any combination of one ormore programming languages, including an object oriented programminglanguage such as Smalltalk, C++, or the like, and procedural programminglanguages, such as the “C” programming language or similar programminglanguages. The computer readable program instructions may executeentirely on the user's computer, partly on the user's computer, as astand-alone software package, partly on the user's computer and partlyon a remote computer or entirely on the remote computer or server. Inthe latter scenario, the remote computer may be connected to the user'scomputer through any type of network, including a local area network(LAN) or a wide area network (WAN), or the connection may be made to anexternal computer (for example, through the Internet using an InternetService Provider). In some embodiments, electronic circuitry including,for example, programmable logic circuitry, field-programmable gatearrays (FPGA), or programmable logic arrays (PLA) may execute thecomputer readable program instructions by utilizing state information ofthe computer readable program instructions to personalize the electroniccircuitry, in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart and/or block diagram blockor blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the block may occur out of theorder noted in the Figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions.

In addition to the above, one or more aspects may be provided, offered,deployed, managed, serviced, etc. by a service provider who offersmanagement of customer environments. For instance, the service providercan create, maintain, support, etc. computer code and/or a computerinfrastructure that performs one or more aspects for one or morecustomers. In return, the service provider may receive payment from thecustomer under a subscription and/or fee agreement, as examples.Additionally or alternatively, the service provider may receive paymentfrom the sale of advertising content to one or more third parties.

In one aspect, an application may be deployed for performing one or moreembodiments. As one example, the deploying of an application comprisesproviding computer infrastructure operable to perform one or moreembodiments.

As a further aspect, a computing infrastructure may be deployedcomprising integrating computer readable code into a computing system,in which the code in combination with the computing system is capable ofperforming one or more embodiments.

As yet a further aspect, a process for integrating computinginfrastructure comprising integrating computer readable code into acomputer system may be provided. The computer system comprises acomputer readable medium, in which the computer medium comprises one ormore embodiments. The code in combination with the computer system iscapable of performing one or more embodiments.

Although various embodiments are described above, these are onlyexamples. For example, computing environments of other architectures canbe used to incorporate and use one or more embodiments. Further,different instructions, commands or operations may be used. Moreover,other security protocols, transmission protocols and/or standards may beemployed. Many variations are possible.

Further, other types of computing environments can benefit and be used.As an example, a data processing system suitable for storing and/orexecuting program code is usable that includes at least two processorscoupled directly or indirectly to memory elements through a system bus.The memory elements include, for instance, local memory employed duringactual execution of the program code, bulk storage, and cache memorywhich provide temporary storage of at least some program code in orderto reduce the number of times code must be retrieved from bulk storageduring execution.

Input/Output or I/O devices (including, but not limited to, keyboards,displays, pointing devices, DASD, tape, CDs, DVDs, thumb drives andother memory media, etc.) can be coupled to the system either directlyor through intervening I/O controllers. Network adapters may also becoupled to the system to enable the data processing system to becomecoupled to other data processing systems or remote printers or storagedevices through intervening private or public networks. Modems, cablemodems, and Ethernet cards are just a few of the available types ofnetwork adapters.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting. As used herein, thesingular forms “a”, “an” and “the” are intended to include the pluralforms as well, unless the context clearly indicates otherwise. It willbe further understood that the terms “comprises” and/or “comprising”,when used in this specification, specify the presence of statedfeatures, integers, steps, operations, elements, and/or components, butdo not preclude the presence or addition of one or more other features,integers, steps, operations, elements, components and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of allmeans or step plus function elements in the claims below, if any, areintended to include any structure, material, or act for performing thefunction in combination with other claimed elements as specificallyclaimed. The description of one or more embodiments has been presentedfor purposes of illustration and description, but is not intended to beexhaustive or limited to in the form disclosed. Many modifications andvariations will be apparent to those of ordinary skill in the art. Theembodiment was chosen and described in order to best explain variousaspects and the practical application, and to enable others of ordinaryskill in the art to understand various embodiments with variousmodifications as are suited to the particular use contemplated.

What is claimed is:
 1. A computer program product for facilitatingprocessing in a computing environment, the computer program productcomprising: a computer readable storage medium readable by a processingcircuit and storing instructions for performing a method, the methodcomprising: performing authentication on a plurality of links to be usedto couple one node of the computing environment and another node of thecomputing environment, the performing authentication including:requesting by the one node generation of a shared key by a key servercoupled to the one node of the computing environment; obtaining by theone node the shared key and an identifier of the shared key from the keyserver; sending the identifier of the shared key from the one node tothe other node; sending an encrypted message from the one node to theother node via one link of the plurality of links, the encrypted messageencrypted with the shared key; receiving by the one node via the onelink an indication that the other node decrypted the encrypted messageusing the shared key obtained by the other node; and repeating thesending the encrypted message and the receiving the indication that theother node decrypted the encrypted message on one or more other links ofthe plurality of links using the shared key previously obtained.
 2. Thecomputer program product of claim 1, wherein the performingauthentication further comprises receiving by the one node via the onelink an indication that the other node obtained the shared key from thekey server.
 3. The computer program product of claim 1, wherein thesending the identifier and the sending the encrypted message are sent asone authentication message, the one authentication message including theencrypted message and the identifier that is in the clear.
 4. Thecomputer program product of claim 1, wherein the indication comprises aresponse encrypted with the shared key, and based on receiving theresponse, a chain of trust is extended to the one or more other links ofthe plurality of links to facilitate authentication of the one or moreother links.
 5. The computer program product of claim 4, wherein basedon the chain of trust, the key server is not further accessed in theauthenticating of the one or more other links of the plurality of links,the authenticating the one or more other links including the repeatingthe sending the encrypted message and the receiving the indication onthe one or more other links.
 6. The computer program product of claim 1,wherein the method further includes establishing by the one node asecure connection with the key server, wherein the establishing uses oneor more certificates installed on the one node and the key server. 7.The computer program product of claim 6, wherein the establishing isperformed a single time for the one node, wherein the performing theauthentication for the plurality of links uses the shared key obtained asingle time from the key server by the one node.
 8. The computer programproduct of claim 6, wherein the requesting generation of the shared keyis based on establishing the secure connection with the key server. 9.The computer program product of claim 1, wherein the requestinggeneration of the shared key from the key server comprises sending acreate request to the key server requesting the shared key, and theobtaining the shared key and the identifier from the key server furthercomprises: obtaining from the key server, based on the requesting, anidentifier of the shared key; sending a get request to the key server toobtain the shared key, the get request including the identifier of theshared key; and obtaining from the key server the shared key.
 10. Thecomputer program product of claim 1, wherein the encrypted messageincludes a set of keys to be used to send or receive further encryptedmessages.
 11. A computer system for facilitating processing in acomputing environment, the computer system comprising: a memory; and aprocessor in communication with the memory, wherein the computer systemis configured to perform a method, said method comprising: performingauthentication on a plurality of links to be used to couple one node ofthe computing environment and another node of the computing environment,the performing authentication including: requesting by the one nodegeneration of a shared key by a key server coupled to the one node ofthe computing environment; obtaining by the one node the shared key andan identifier of the shared key from the key server; sending theidentifier of the shared key from the one node to the other node;sending an encrypted message from the one node to the other node via onelink of the plurality of links, the encrypted message encrypted with theshared key; receiving by the one node via the one link an indicationthat the other node decrypted the encrypted message using the shared keyobtained by the other node; and repeating the sending the encryptedmessage and the receiving the indication that the other node decryptedthe encrypted message on one or more other links of the plurality oflinks using the shared key previously obtained.
 12. The computer systemof claim 11, wherein the sending the identifier and the sending theencrypted message are sent as one authentication message, the oneauthentication message including the encrypted message and theidentifier that is in the clear.
 13. The computer system of claim 11,wherein the indication comprises a response encrypted with the sharedkey, and based on receiving the response, a chain of trust is extendedto the one or more other links of the plurality of links to facilitateauthentication of the one or more other links.
 14. The computer systemof claim 13, wherein based on the chain of trust, the key server is notfurther accessed in the authenticating of the one or more other links ofthe plurality of links, the authenticating the one or more other linksincluding the repeating the sending the encrypted message and thereceiving the indication on the one or more other links.
 15. Thecomputer system of claim 11, wherein the requesting generation of theshared key from the key server comprises sending a create request to thekey server requesting the shared key, and the obtaining the shared keyand the identifier from the key server further comprises: obtaining fromthe key server, based on the requesting, an identifier of the sharedkey; sending a get request to the key server to obtain the shared key,the get request including the identifier of the shared key; andobtaining from the key server the shared key.
 16. A computer-implementedmethod of facilitating processing in a computing environment, thecomputer-implemented method comprising: performing authentication on aplurality of links to be used to couple one node of the computingenvironment and another node of the computing environment, theperforming authentication including: requesting by the one nodegeneration of a shared key by a key server coupled to the one node ofthe computing environment; obtaining by the one node the shared key andan identifier of the shared key from the key server; sending theidentifier of the shared key from the one node to the other node;sending an encrypted message from the one node to the other node via onelink of the plurality of links, the encrypted message encrypted with theshared key; receiving by the one node via the one link an indicationthat the other node decrypted the encrypted message using the shared keyobtained by the other node; and repeating the sending the encryptedmessage and the receiving the indication that the other node decryptedthe encrypted message on one or more other links of the plurality oflinks using the shared key previously obtained.
 17. Thecomputer-implemented method of claim 16, wherein the sending theidentifier and the sending the encrypted message are sent as oneauthentication message, the one authentication message including theencrypted message and the identifier that is in the clear.
 18. Thecomputer-implemented method of claim 16, wherein the indicationcomprises a response encrypted with the shared key, and based onreceiving the response, a chain of trust is extended to the one or moreother links of the plurality of links to facilitate authentication ofthe one or more other links.
 19. The computer-implemented method ofclaim 18, wherein based on the chain of trust, the key server is notfurther accessed in the authenticating of the one or more other links ofthe plurality of links, the authenticating the one or more other linksincluding the repeating the sending the encrypted message and thereceiving the indication on the one or more other links.
 20. Thecomputer-implemented method of claim 16, wherein the requestinggeneration of the shared key from the key server comprises sending acreate request to the key server requesting the shared key, and theobtaining the shared key and the identifier from the key server furthercomprises: obtaining from the key server, based on the requesting, anidentifier of the shared key; sending a get request to the key server toobtain the shared key, the get request including the identifier of theshared key; and obtaining from the key server the shared key.